home *** CD-ROM | disk | FTP | other *** search
-
- ****************************************************************************
- * GLE for OS/2 3.3 h *
- * *
- * ported by Axel Rohde *
- ****************************************************************************
-
- A little bit history:
- ---------------------
-
- 32 bit DOS version of GLE by Axel Rohde
- ---------------------------------------
-
- Introduction: (By Chris)
- For a long time I have been explaining to people that a 32bit
- dos version of GLE was not possible with currently available
- compilers and libraries.
- Clearly Axel has no appreciation for the impossible and has gone
- ahead and compiled a version anyway (with absolutely no assistance
- from me). On any 386 or better machine this version of GLE should
- run without problems, it's main features are these:
- 1) No 640K memory restrictions.
- 2) Much faster.
- :
- :
- :
-
-
- This happened a few months ago, after compiling GLE under Linux in october
- 1993. GLE 32 for DOS was released in January 1994. Now, it's:
-
- GLE for OS/2
- ------------
-
- ------------------------------------------------------------------------------
-
-
- Installation
- ------------
-
- First of all, get the runtime package of EMX (EMX is the GNU C port for
- OS/2 by Eberhard Mattes), if it is *not* included in this package. It is
- included, if you can find emx.exe, emx.dll.... in the \glepm\exe directory.
- The runtime package is called emxrt.zip and is available for anonymous
- ftp on:
-
- ftp.uni-stuttgart.de [129.69.8.13]: /pub/systems/os2/emx-0.8h
- ftp-os2.cdrom.com: [192.153.46.2]: /os2/2_x/unix/gnu/emx08h
- src.doc.ic.ac.uk [146.169.2.1]: /pub/packages/os2/2_x/unix/gnu/emx08h
- ftp.informatik.tu-muenchen.de [131.159.0.198]:
- /pub/comp/os/os2/devtools/emx+gcc
-
- If you don't already have unzip, get it, it's available on these sites, too.
- Don't forget to switch your ftp utility into the binary mode.
-
- Unzip the archives of GLE for OS/2 and EMX with
- unzip something.zip
-
- or, if you use pkunzip
- pkunzip -d something.zip
-
-
- You must set the environment variable GLE_TOP, include the directory,
- where the executables are in the PATH environment and the directory,
- where the DLL's of EMX are in the LIBPATH environment.
-
- Change/add the following lines in your config.sys:
-
- set GLE_TOP=c:/glepm
- set PATH=......;c:\glepm\exe
- set LIBPATH=......;c:\emx\dll
-
- A slash at the end of GLE_TOP is no more important in this version.
- This example assumes, that you installed GLE and EMX on drive C.
-
- Reboot your computer, and GLE is ready to run....
-
-
-
- Differences between GLE for OS/2, for DOS and for UNIX/X-Window-System
- ----------------------------------------------------------------------
- and instructions to use
- -----------------------
-
- If gle_vga (DOS) draws a graph onto the screen, it switches from text- to
- the graphics-mode. The editor of gle_x (X-Windows) runs in text-mode, too.
- If it draws a graph, it forces the X-Windows server to create a new window
- on a specified display and draws into it. Under OS/2, it is possible
- to run a OS/2 text-mode program in a PM Window, but it's impossible (or
- not documented), to force the PM to create a new window and to draw into
- it. Gnuplot for PM calls *another* program (gnupmdrv.exe) to do the drawing
- stuff. Since OS/2 programs are marked as FullScreen (text-mode, only in
- fullscreen mode), WindowCompatible (text-mode, windowable) or WindowAPI
- (PM program), and I did not want to rewrite the text-mode part of GLE to
- use a 'Vio Presentation Space' (since EMX has no Borland-compatible
- text-mode library, I rewrote some text-mode calls using EMX calls, though),
- the editor of GLE runs in text-mode, as usual. gle_pm and surf_pm are
- marked WindowCompatible. If GLE draws onto the PM, it writes the text being
- edited into a temporary file (gleos2.tmp) and starts *itself* again. It is
- possible to start a WindowCompat marked program as a PM program using the
- following command (is it a bug? I hope, it will never be fixed!):
-
- start /pm program
-
- gle_pm and surf_pm use the API-call DosStartSession() to do this. GLE and
- SURFACE determine what to do from their commandline-arguments. They switch
- into displaying mode, when they get the DRAW option:
-
- start /pm gle_pm /draw gleos2.tmp
- start /pm surf_pm surfos2.tmp /d /o -b something.sur
-
- If the drawing is finished, GLE normally prints error messages to the
- screen, if there are any. Since I don't know yet, how to make the editor-
- and the drawing-instance communicate with each other (shared memory,
- pipes, semaphores... all these IBMisms. Chris Pugmire, the author of GLE,
- might not be able to regcognize his source, if I implement this :^), the
- drawing instance of gle_pm displays a message on it's title bar, if
- there were errors, warnings or messages during compilation. You can go
- back to the editor instance of gle_pm by using the keystroke ALT+TAB.
- Then press F5 to display these messages. gle_pm writes them into the file
- GLEOS2.ERR. surf_pm behaves a little bit different. You won't see any
- graphics window, if there are severe errors, since it does not display
- anything if errors happen. If no graphics window appears after pressing
- F10, you should press F5 and take a look at the error messages.
-
- The graphics-instances are *replaced* , if there is one running and you
- press F10 again. The old graphics-instance was killed by DosStopSession().
-
- The graphics portion of GLE_PM draws into a visible 'micro Presentation
- Space'. If the drawing is finished, a memory micro Presentation Space
- (a bitmap) is allocated and the contents of the drawing is copied into
- it. This enables quick redrawing of the window contents, if it was hidden
- behind another window and made visible again. Then, the reverse
- BitBlockTransfer operation happens, the bitmap is written back onto the
- screen. This also happens, if the window-focus changes (if you click onto
- an other window) when GLE is drawing. The window's contents is copied into
- the bitmap and further drawing is done into the bitmap.
-
- gle_pm does not always listen for PM messages, therefore it may lock the
- PM (the PM has only *one* message queue) for a short time. Press Ctrl-Esc
- if the PM is locked. After a short time, a dialog box will appear. It
- allows to terminate the drawing instance of gle_pm/surface_pm.
-
-
-
- Speed
- -----
- GLE_PM and SURF_PM under OS/2 2.x are no longer much slower than GLE
- for DOS or Linux / X-Window System. I sped up the performance of PM line
- drawing and moving by simply buffering the calls and flushing them from
- time to time by using only one Gpi call. The overhead of the Graphics
- Programming Interface is reduced and therefore does not consume much time.
-
- A new feature of this version is the ability to fill paths. A path consist
- of line and move commands and can be filled. In the PostScript language,
- a character of a font is a filled path. One can not simply replace a filled
- path by a filled polygon, since a path can consist of move commands, a
- polygon consists of lines only. The Graphics Programming Interface (GPI)
- of the PM is able to draw and fill paths. Due to this complexity, the
- GPI is quite slow.... Since one can not buffer move-calls inside a path,
- gle_pm does not fill characters by default (all tex**** fonts are filled
- paths). This inceases the drawing speed by more than a factor of two.
- If you set the environment-variable GLEPMFONTFILL to something, e.g.
-
- set GLEPMFONTFILL=1
-
- gle_pm fills fonts, too.
-
- To increase speed, gle_pm will never draw both, the outline and the filled
- interior. You will not always see an outline around a filled area.
- However, if the background color is white, gle_pm draws the outline and
- not the interior. gle_pm knows about the winding rule, but it can not
- reverse a path..... The best way, to preview gle drawings that use a path,
- is to use Ghostscript (see below), since the interactive drivers can only
- *emulate* PostScript specials with calls of an other graphics libraries.
- But they are much faster.....
- Clipping isn't supported yet.
-
- After realising, that drawing thick lines in a PM window is slow and
- only possible inside of a path environment, I removed the code that
- switches between line-widths. gle_pm can draw shade and grid patterns
- (see shade.gle, dvifill.gle or wallx.gle). They look different compared
- to the output of GLE_PS + Ghostscript (a postscript emulator).
- There are only 8 different line-styles available. It is not possible,
- to define new line-styles and grid/shade patterns like under Turbo-C's BGI
- or under the X-Window System. This version draws (filled or not filled)
- circles or rectangles correctly, in other words, the can be stretched or
- rotated.
-
-
- OS/2 2.x still *loves* RAM and large datasets cause swapping and slow it
- down, if you have 8MB or less. The harddisk cache isn't as good as smartdrv
- under DOS and should be resizeable as Linux's (shrink, when applications
- need more memory).
-
- A number of applications write a lot of data to the disk. If disk-writes
- are cached, the performance increases under normal circumstances.
- Due to this fact, I recommend a cache-size of 1MB on 8MB systems.
- To enable lazy-writing with a large delay, add the following (or a similar)
- line to the config.sys:
-
- RUN=C:\OS2\CACHE.EXE /MaxAge:120000 /DiskIdle:60000 /BufferIdle:60000
-
- However, this is not true for surf_pm, since there is a brake somewhere in
- the library code between fprintf() <-> DosWrite().
- Write-cacheing has nearly no effect....... The time needed to write
- a bigfile onto a RAM-disk does not differ from the time to write it
- onto a normal harddisk.
-
- Surface was dramatically slower under OS/2 than under DOS or Linux.
- Therefore, I added a new command to the surface language: NOBIGFILE.
- NOBIGFILE prevents surface from writing *bigfiles* to the disk. It's not
- neccessary to write bigfiles to the disk during the 'design' phase.
- For the final run, place an exclamation mark in front of NOBIGFILE.
-
- Time needed to 'surface' jack.sur in seconds:
-
- Linux OS/2 OS/2(cached graphics) DOS 16bit DOS 32bit
- ---------------------------------------------------------------
- bigfile: 4.5 12.5 11 5.5 5.5
-
- nobigfile: 2 ---- 3 --- 2.5
-
-
-
- The time to draw jack.big with GLE (gle_xxx jack) in seconds does not vary
- much between all systems:
-
- Linux OS/2 OS/2(cached graphics) DOS 16bit DOS 32bit
- ---------------------------------------------------------------
- 6.5 ---- 7 ---- 6
-
-
- New features
- ------------
-
- GLE searches for gle-files to inlude in three directories:
- The current directory, in GLE_TOP/lib and in a user-specified directory,
- which can be made known to GLE by setting the environment-variable
- GLE_USRLIB. This especially useful on multi-user systems.
-
- set GLE_USRLIB=f:/users/jones/glelib
-
-
- RESTRICTIONS and BUGS
- ---------------------
-
- 1) The vector-fonts of the GLE for OS/2 are compatible to those from
- GLE 32 for DOS and Linux. They are not compatible to 16 bit fonts
- that come with the 16 bit release of GLE for DOS (by Chris Pugmire).
- They may be compatible to fonts that were created under other
- (small endian-) 32-bit operating-systems. If you use GLE under Linux,
- too, it may be a good idea to mount the DOS-partition, that contains
- GLE 32 or GLE for OS/2 (including fonts) and create a link:
-
- ln -s /dospartition-mount-directory/gle32/font /usr/local/gle/font
-
- If there is GLE 32 for DOS somewhere on a DOS partition (for example
- f:), simply erase the fonts in the GLE-for-OS/2-directory and set
- GLE_TOP=f:/gle32/. Graph.hlp and graph.idx and are in a different
- format in the DOS version, therefore you should store the DOS and
- the OS/2 graph.* files at a safe location, for example
- f:\gle32\help.os2 and f:\gle32\help.dos.
-
- Add the following line to your DOS-autoexec.bat:
-
- copy f:\gle32\help.dos\graph.* f:\gle32
-
-
- Add the following line to your OS/2-config.sys:
-
- call=c:\os2\xcopy.exe f:\gle32\help.os2\graph.* f:\gle32
-
- This will save approximately 900 kB harddisk space!
-
-
-
- Getting help on commnon GLE problems
- ------------------------------------
-
- There is a mailing list to get and give help on GLE problems.
-
- To subscribe send a mail to:
- listserver@tbone.biol.scarolina.edu
- with a message containing:
- sub glelist <your name>
-
- You can then ask questions or send messages, bug reports or work-arounds
- by email to:
- glelist@tbone.biol.scarolina.edu.
-
-
-
- Related software
- ----------------
-
- The graphics language GLE can be called a subset of Postscript.
- Path filling or clipping for example is only completely supported on
- Postscript devices. I recommend to get the Postscript-interpreter
- 'Ghostscript' from an ftp site.
- Ghostscript can display and print Postscript files which were produced
- by gle_ps on the screen and on non-Postscript capable printers.
- Ghostscript can convert Postscript files to various bitmap formats for
- inclusion into word-processor documents. There's a PM and Windows
- interface called GVPM. Ghostscript is free usable (GNU Public License),
- fast and reliable. OS/2 comes with Postscript fonts (directory:
- psfonts\*.pfb) and Ghostscript can use them. The quality of most of the
- fonts, that come along with Ghostscript, isn't very high.
- The TeX fonts, that come with GLE, have a nice appearance, if you use
- gle_ps and Ghostscript.
-
-
- Access to the patches for the source
- ------------------------------------
-
- The complete sources are at least available from Chris Pugmire's
- FTP-server tui.marc.cri.nz (161.29.1.128). GLE for OS/2 (binaries)
- are available from ftp.informatik.tu-muenchen.de (131.159.0.198),
- and from Chris Pugmire's site, too. If you like to upload GLE to other
- ftp-servers, please do it :^)
-
-
-
- Postscript documentation
- ------------------------
-
- The original Postscript documentation of GLE 3.2 has been replaced by
- Stefan Mundt's reworked version. It can be printed on Postscript Printers
- or with Ghostscript on supported, non Postscript capable printers.
- I omitted the very large appendix. It contains tables of various fonts.
- It's seperately available from tui.marc.cri.nz, too.
-
-
- LEGAL STUFF
- -----------
-
- Copyright-holders are:
-
- GLE: Please ask Chris Pugmire.
-
- EMX/GCC: Eberhard Mattes, Free Software Foundation.
-
- Ghostscript: Aladdin Enterprises.
-
- Postscript: Adobe.
-
- MS-DOS, Windows: Microsoft Corporation.
-
- OS/2,
- Presentation
- Manager: IBM Corporation.
-
- Turbo-C, BGI: Borland.
-
- X Window System: X Consortium, MIT.
-
- I should not forget:
-
- Linux: Linux Torvalds and a lot of other people, far too much
- to be listed here.
-
-
- Legal stuff (selfprotection)
- ----------------------------
-
- LIKE ANYTHING ELSE THAT'S FREE, GLE FOR OS/2 AND ITS ASSOCIATED UTILITIES
- ARE PROVIDED AS IS AND COME WITH NO WARRANTY OF ANY KIND, EITHER EXPRESSED
- OR IMPLIED. IN NO EVENT WILL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DAMAGES
- RESULTING FROM THE USE OF THIS SOFTWARE.
-
- These programs are distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
- Reporting bugs
- --------------
-
- Bug-reports are wellcome (to me and Chris Pugmire). It can not be guaranteed
- that they will be fixed. You should report bugs, that seem to be unique to
- GLE 32 and GLE for OS/2, to me. Please include a complete description of the
- bug, the version of GLE and the GLE files with data.
-
-
- Axel Rohde
- email: exp109@physik.uni-kiel.d400.de
-
- Chris Pugmire's email adress: in%"srghcxp@grv.dsir.govt.nz"
- srghcxp@grv.dsir.govt.nz
-
-
-
- Thanks to:
- ----------
-
- Chris Pugmire for creating GLE.
-
-
- Eberhard Mattes for porting GCC to OS/2 (and DOS), and for emTeX,
- of course.
-
- all the GCC and Gnu people and all other people, who write free software.
-
- Lars Petersen for OS/2 documentation.
-
- Hartmut Schirmer for BCC2GRX, GRX under Linux and help with GLE 32.
-
- Kordt Griepenkerl for the book and for bug-reports.
-
- Ed Nather for reporting bugs + fixes.
-
- Andrey Grozin for the contribution of the
- Feynman Diagram Library.
-
- Joe Huber for the hint, that ecvt() is never used.
-
- Dream Theater,
- Fates Warning,
- Queensrÿche,
- Dire Straits,
- Megadeth,
- and other bands. for protecting me against the noise of
- OS/2 swapping on the HardDisk.
-
- Thanks to that guy who sold me cheap 16MB RAM to shut up OS/2.....
-
-
-
- Happy GLEing,
- Axel Rohde
- January 1995
-